So, I choose not to share the World with BeforeAll and AfterAll hooks. It was easier to implement, cucumber-js also does that, and it prevents the users trying to share things using the World that would actually be lost because - if I am not wrong - the World is newly instanciated for each scenario.

But still, BeforeAll and AfterAll could be used for globally settin-up and cleaning-up things like database, browsers, and things related to the subject under test.

What do you think?

Question: should we prevent invoking those hooks in dry-run?

Should these hooks have access to World

No they should not, it doesn't make sense and doesn't cause any issues

I have kept AfterConfiguration as well as BeforeAll

That's fine, but in my eyes why don't we just move the logic from AfterConfiguration to BeforeAll - maybe over 2 majors. The concept of anything with the word After in it being ran first is just plain wrong imo.

Should we prevent running hooks in dry run

Yes because dry-run should concern itself with things that a feature/scenario may or may not do (Not a suite). But I am not overly concerned with this

Should these hooks have access to World

No they should not, it doesn't make sense and doesn't cause any issues

👍

I have kept AfterConfiguration as well as BeforeAll

That's fine, but in my eyes why don't we just move the logic from AfterConfiguration to BeforeAll - maybe over 2 majors. The concept of anything with the word After in it being ran first is just plain wrong imo.

So I would suggest to deprecate AfterConfiguration in favor of InstallPlugin rather than BeforeAll. InstallPlugin hook has the configuration object, BeforeAll has not.

Should we prevent running hooks in dry run

Yes because dry-run should concern itself with things that a feature/scenario may or may not do (Not a suite). But I am not overly concerned with this

👍
I'll see what I can do

As part of this PR, I've added a short document to summarize all the hooks and their purpose.

Could you please review it? It is there: features/docs/writing_support_code/hooks/README.md

2 second look looks good for docs, I'll have plenty of review comments but it'll be minor polishes. I'll get to reviewing it in the next day or so. (if you can hold out till then that'll be good).

2 second look looks good for docs, I'll have plenty of review comments but it'll be minor polishes. I'll get to reviewing it in the next day or so. (if you can hold out till then that'll be good).

No worries, no rush, take your time :)

Should these hooks have access to World

There is a use-case for these hooks being able to set some kind of read-only initial state/context so that, for example, you could access the database connection you created in the BeforeAll hook from step defs. There are obviously other ways of doing this in Ruby, but if we can see a way to do this and avoid people having to use class props / global variables, that would be nice.

For example, we could pass a reference to a mutable test_run_context hash into this hook, which we then surface as a read-only hash in the World hook.

Of course, we can do that as a second iteration.

There is a use-case for these hooks being able to set some kind of read-only initial state/context so that, for example, you could access the database connection you created in the BeforeAll hook from step defs. There are obviously other ways of doing this in Ruby, but if we can see a way to do this and avoid people having to use class props / global variables, that would be nice.

For example, we could pass a reference to a mutable test_run_context hash into this hook, which we then surface as a read-only hash in the World hook.

Of course, we can do that as a second iteration.

As you said, I suggest to do that as part of a second iteration, or even just waiting for user feedback and requests